AWS MediaServices で DRM を使用する際に出てくるキーワード「SPEKE」を理解する
こんにちは、大前です。
「動画配信をしたい」 という要望に対し、「コンテンツの保護どうしましょう?」という議論は必ず発生するものかと思います。
コンテンツ保護を実現する方法として HLS+AES128 や DRM を採用する事になった際、AWS での実現方法を調べると SPEKE という見慣れない単語に出会った方もいるのではないでしょうか。
本記事は、AWS で HLS+AES128 や DRM を行う際に出てくるキーワードである SPEKE とはなんぞやについて説明をしていきたいと思います。
「そもそも HLS+AES128 とか DRM って何?」という方はまずは以下のブログを一読頂ければと思います。
SPEKE とは
突然現れた SPEKE という単語、聞いた事すらない方も多いのではないでしょうか。
AWS 公式ドキュメント(SPEKE: Secure Packager and Encoder Key Exchange API)では、SPEKE について以下の説明がされています。
SPEKE は、Secure Packager and Encoder Key Exchange (SPEKE) の略語です。これはロイヤリティフリーのオープンソース API 仕様で、ライブおよびオンデマンドのストリーミング動画向けに、動画エンコーダー、トランスコーダー、オリジンサーバーとデジタル著作権管理 (DRM) システムキーサーバーの間の暗号化通信の標準を定義するものです。
・・・なんだかわかる様な、わからない様な感じですね。
「DRM とかに関連する API 仕様なんだな」ぐらいは把握できるかもしれませんが、SPEKE についてもっと理解を深める為に、「そもそもなぜ SPEKE が存在するのか」を紐解いていきましょう。
DRM の一般的なフロー
まず前提として、DRM の一般的なフローについてざっくりと理解をしましょう。
主な登場人物としては以下が存在します。
- エンクリプタ
- DRM システム
- ユーザー(動画プレイヤー)
1.コンテンツの暗号化
まずはじめに、エンクリプタが DRM システムから暗号鍵を受け取りコンテンツを暗号化します。
ここで言うエンクリプタは、AWS MediaServices では MediaPackage などが該当する形となります。
2.再生のリクエスト
ユーザーはコンテンツを取得し、動画プレイヤーによる再生を試みますが、コンテンツは暗号化されている為当然そのままでは再生が出来ません。
そこで、動画プレイヤーは DRM システムに対し視聴リクエストを行います。
3.復号
DRM システムは受け取った視聴リクエストに対して復号鍵を返却します。
動画プレイヤーが受け取った復号鍵でコンテンツを復号する事により、ユーザーは動画を視聴する事が可能となります。
かなりざっくりですが、DRM の大まかなフローは上記のイメージを持ってもらえればとりあえず大丈夫です。
SPEKE がない世界のお話
DRM システムの特徴として、DRM システム毎に対応している再生環境が異なる というものがあります。
代表的な DRM システムとしては Google の Widevine、Apple の FairPlay、Microsoft の PlayReady 等が挙げられますが、それぞれ対応する再生環境が異なる為、幅広い再生環境に対応しようとした場合には複数の DRM システムを併用する事が一般的です。
この時、エンクリプタはコンテンツの暗号化を行う為に各 DRM システムとやりとりを行うわけですが、DRM システム毎にインターフェースが異なるとエンクリプタ側で各 DRM のインターフェース仕様に対応する必要があり、非常に複雑なシステムとなってしまいます。
SPEKE が解決する事
上記の課題を解決するのが、今回のキーワードである SPEKE です。
冒頭に記載した SPEKE の説明文にもある通り、SPEKE とは オリジンサーバーとデジタル著作権管理 (DRM) システムキーサーバーの間の暗号化通信の標準を定義 したインターフェース仕様です。
SPEKE を使用する事により、DRM システムが何種類存在したとしても共通のインターフェース仕様でやりとりを行う事が出来るようになります。
もっと SPEKE について知りたい!
SPEKE のより詳細な説明については無料のデジタルトレーニングがありますので、気になる方はこちらを受講してみてください。
Digital Rights Management and the SPEKE Protocol in Video Workflows
"なぜ SPEKE が必要なのか" から始まり、インターフェースでどんな情報をやりとりしているかまでわかりやすく解説されているので、オススメです。
SPEKE を使用した HLS+AES128 のライブ配信をやってみる
では実際に SPEKE を使用して暗号化を行うライブ配信をやってみたいと思います。
awslabs に SPEKE を MediaPackage もしくは MediaConvert と連携させるためのソリューションガイドがある為、今回はこちらを使っていきます。
また、DRM の個人利用はハードルが高い為、今回は上記ソリューションを使用した HLS + AES128 のライブ配信になります。DRM ではありませんが、使用する仕組みは同じです。
全体構成は以下になります。API Gateway + Lambda 部が キーサーバとなり、MediaPackage が SPEKE 仕様に則ってキーサーバと鍵情報をやりとりする形になります。
MediaLive と MediaPackage は既に作成されているものとします。MediaLive や MediaPackage の設定方法については、下記ブログ等を参照ください。
CloudFormation テンプレートからスタックを作成
まずは、SPEKE Reference Server Installation に従って CloudFormation テンプレートからリソースを展開します。
テンプレートとして https://s3.amazonaws.com/rodeolabz-us-east-1/speke/speke_reference.json を指定します。
今回はパラメータはデフォルトのまま、スタック名のみ入力して進みます。
最後に、IAM リソース作成に関するチェックボックスにチェックを入れ、スタックの作成を実行します。
リソースが作成完了するまで少し時間がかかるため、のんびり待ちましょう。
この CloudFormation によって作成される主なリソースは以下です。
- キーサーバ(API Gateway + Lambda)
- キーを格納するための S3 バケット
- 上記 S3 をオリジンとする CloudFront
- MediaPackage からキーサーバを呼び出す為に必要な IAM ロール
また、デプロイされるキーサーバーの実装は以下で確認する事が出来ます。独自でキーサーバーを実装する必要がある場合には参考にしてみてください。
CloudFront のオリジンを修正
上記にて CloudFront + S3 構成のリソースが作成されていますが、作成したばかりの S3 では以下ブログの事象が発生する可能性が高い為、CloudFront の Origin 設定を少し修正します。
詳細は上記ブログを参照頂ければと思いますが、Origin Domain Name にリージョンを表す文字列を追記します。
この際、Origin Access Identity の設定がデフォルト状態に戻ってしまうので、Use an Existing Identity を選択しなおしてから保存しましょう。
MediaPackage のエンドポイント設定
最後に、MediaPackage のエンドポイント設定を行います。
先ほど実行した CloudFormation の 出力 にエンドポイントの設定に必要な情報が表示されているので、こちらを元に設定を行なっていきます。
MediaPacakge のエンドポイントの追加/編集から設定を追加したいエンドポイントを選択し、以下項目を設定します。
- Resource ID ... 任意の文字列を指定します。UUID などを入力しておけば無難です。
- System IDs ... DRM を使用する場合、DRM システム毎に決められているシステム ID を指定する必要があります。AES128 にはシステム ID がない為、キーサーバ側の実装に合わせて文字列を記載します。このソリューションでキーサーバーをデプロイした場合は、81376844-f976-481e-a84e-cc25d39b0b33 を入力してください。
- URL ... 上記 CloudFormation の出力部分に表示されている SPEKEServerURL の値を指定します。
- Role ARN ... 上記 CloudFormation の出力部分に表示されている MediaPackageSPEKERoleArn の値を指定します。
配信してみる
これで、一通りの設定は完了です。実際に配信を行い、HLS + AES128 暗号化が行われている事を確認してみます。
MediaLive にて配信を開始し、少し経った後に MediaPackage エンドポイントの Manifest preview を確認してみると、EXT-X-KEY に AES-128 で暗号化を行なう為の記載がされている事が確認できます。
VideoJS HLS にて動画を再生しつつ、Chrome の開発者ツールを用いてリクエストを確認してみます。
問題なく動画が再生される事と、S3 に格納されている鍵を定期的にリクエストしている事が確認できました。
問題なく HLS + AES128 での配信が出来ました!
おわりに
MediaServices で DRM などを行おうとした場合に出てくるワードである SPEKE について概要を説明した上で、実際に SPEKE によるキーサーバーをデプロイし、HLS + AES128 による動画配信を行なってみました。
HLS + AES128 に関しては今回用いた公式のソリューションを用いれば簡単に実現する事が出来ます。
DRM については各種 DRM システムとの契約なども必要になってくる為自社で導入するハードルは高いですが、「AWS で DRM を使用する場合には SPEKE という I/F 仕様に則ってキーサーバーを実装する必要があるんだな」という事を頭の片隅に入れておくと良いかと思います。
この記事を読んだ方が少しでも SPEKE について理解を深めて頂ければ幸いです。
動作確認後は各種リソースの止め忘れ、消し忘れにご注意を。
以上、AWS 事業本部の大前でした。
参考
- 動画配信におけるコンテンツ保護の重要性とそれを実現する仕組みを自分なりにまとめてみた
- SPEKE: Secure Packager and Encoder Key Exchange API
- Widevine
- FairPlay
- PlayReady
- Digital Rights Management and the SPEKE Protocol in Video Workflows
- SPEKE Reference Server
- OBSとAWS Elemental MediaLiveでライブ配信をしてみた
- SPEKE Reference Server Installation
- speke-reference-server/src/
- S3+CloudFrontでS3のURLにリダイレクトされてしまう場合の対処法
- VideoJS HLS